Re-design logic for commandfor form-owner combinations #49594
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In whatwg/html#9841 the behaviour for
commandfor= as a form owner has subtly changed:
now does nothing (so we will log a warning to the console telling
the user that this is the case and they should add
type=button
tomake it a command button).
that have a form owner should do the behaviour explicitly laid out
by their
type
, and ignore andcommand
/commandfor
attributessemantics. In this case we log a warning to the console telling
the user that the command/commandfor are being ignored.
To keep changes light here, only the
DefaultEventHandler/CommandForElement logic has changed; a more
significant refactor might be needed to adjust
type_
to ensure it does not resolve tokSubmit
implicitly, but that should be handled more delicately, I believe.Bug: 382238696
Change-Id: I7d5583d34a2d615faeed80905816edb3f261d60d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6070260
Auto-Submit: Keith Cirkel <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Keith Cirkel <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1393810}